home *** CD-ROM | disk | FTP | other *** search
- Path: anvil.ugrad.cs.ubc.ca!not-for-mail
- From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
- Newsgroups: comp.lang.c
- Subject: Re: fast find algorithm
- Date: 11 Apr 1996 12:00:36 -0700
- Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
- Message-ID: <4kjkskINNmf9@anvil.ugrad.cs.ubc.ca>
- References: <Dp8wE6.8DG@cix.compulink.co.uk> <4kbrg8$luu@druid.borland.com> <316B2716.4993@airmail.net> <4kjahn$jp2@druid.borland.com>
- NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca
-
- In article <4kjahn$jp2@druid.borland.com>,
- Pete Becker <pete@borland.com> wrote:
- >In article <316B2716.4993@airmail.net>, markn@airmail.net says...
- >>
- >>Pete Becker wrote:
- >>>
- >>> If you use a linked list at each array location to resolve conflicts
- >then
- >>> you can delete elements.
- >>
- >>Knuth gives an algorithm for deleting elements from a table when using linear
- >pr
- >>obing,
- >>and it's pretty easy to see how that would work. I'm not sure there is a
- >practi
- >>cal
- >>way to remove elements when using a secondary hash probe...
- >
- >Good point: with linear probing you know where the next location is, and sooner
- >or later you know that you're done. My guess is that deleting would be constant
- >time in most cases, but O(n) worst case, where n is the size of the table.
-
- The way you delete elements from a hash table is that instead of making a
- vacant spot of a deleted item, you put in a ``tombstone''. When probing for a
- subsequent insertion, when you come upon the tombstone, you place the new
- element there, but when searching for an existing element, you skip over the
- tombstone and keep probing.
-
- This way you can use good probing functions that cycle through all the residues
- modulo the table size without searching linearly and introducing primary
- clustering.
- --
-
-